FIG. 1 gives a schematic system view of a Portal server implementing such a prior art Web Portal. A prior art Portal, such as e.g., IBM WebSphere Portal or Jetspeed2 Enterprise Portal (www.Portals.apache.org/jetspeed-2/Portal-design.html), is built by a complex functionality implemented on a network server—for example a Web server 100, the most important elements of which are logic components for user authentication 105, state handling 110, aggregation 115 of fragments, a plurality of Portlets 120—further described below—provided in respective pages 125 with a respective plurality of APIs 130 to a respective Portlet container software 135 for setting them into the common Web page context, and some Portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required. This is roughly depicted in FIG. 1.
In more detail, a Portal engine of the Web server in FIG. 1 implements an aggregation of Portlets 120 based on the underlying Portal model 150 and Portal information such as security settings, user roles, customization settings, and device capabilities. Within the rendered page, the Portal automatically generates the appropriate set of navigation elements based on the Portal model. The Portal engine invokes Portlets during the aggregation as required and when required and uses caching to reduce the number of requests made to Portlets. The prior art IBM WebSphere Portal employs open standards such as the Java Portlet API (application programming interface). It also supports the use of a remote Portlet via the WSRP standard.
The Portlet container 135 is a single control component competent for all Portlets 120, which may control the execution of code residing in each of these Portlets. It provides the runtime environment for the Portlets and facilities for event handling, inter-Portlet messaging, and access to Portlet instance and configuration data, among others. The Portal resources 140 are in particular the Portlets 120 themselves and the pages 125, on which they are aggregated in form of an aggregation of fragments. A Portal database 128 stores the portlet description, this is in detail the portlet description featuring some attributes like portlet name, portlet description, portlet title, portlet short title, and keywords; the portlet interaction interface description, which is often stored in form of WSDL documents. The Portal database also stores the Portal content structure, i.e. the hierarchical structure of portal pages—which may again contain nested pages—and portlets. This data is stored in the database 128 in an adequate representation based on prior art techniques like relational tables.
The before-mentioned aggregation logic 115 includes all steps that are required to assemble a page. Typically, these steps are to load a content structure from storage, to traverse it and to call the instances referenced in the structure in order to obtain their output, which is assembled to a single page. The content structure may be defined through e.g. Portlet Customization by the administrators or users and saved in the database, or by other ways, e.g. scripting, xml import, etc.
A graphical user interface component 160 is provided for manually controlling the layout of the plurality of rendered pages. By that interface 160 a Portal administrator is enabled to control the visual appearance of the Web pages. In particular, the Administrator can decide which Portal is rendered at which location next to which other Portlet at a given Web page.
With particular reference to the focus of the present invention the structure behind a Portal is illustrated by way of a tourist information Portal example in FIG. 2. Such prior art portal is made up of a hierarchical structure 200 of portal pages, see the circles 201 to 210—which may again contain nested pages, see 201 to 206—and portlets 211 to 217. Such structure is generally referred to herein as “content structure”. Of course, the Portlets 211 to 217 are not restricted to be located at one and the same hierarchy level (as depicted in FIG. 2); instead they can be distributed over any level.
With reference to FIGS. 2 and 3, in more detail, page 201 is the homepage of the portal. The homepage 201 comprises amongst other graphical elements three links leading to pages 202, 203, and 204. Page 202 comprises again another link which leads to page 205 which intern comprises links leading to pages 207 and 208. A similar structure is repeated for page 204 leading to pages 206, 209 and 210. A similar structure could be appended beneath page 203, which is suppressed here in order to increase clarity of the drawing.
In this example page 207 comprises two portlets 211, 212. Portlet 211 shows the train schedule and portlet 212 is a portlet which guides the user when he wants to buy an online ticket. Under page 208 a portlet 213 related to rental cars is provided. Further under page 208, a trip planning portlet 214 is provided. Further, under page 209 a flight booking portlet 215 and a news portlet 216 is provided. Finally under page 206 a further page 210 comprising a telephone book portlet 217 is provided.
In prior art, the portal content structure as exemplarily depicted in FIG. 2 in a simplified manner is manually defined by portal administrators and users, using above interface 160 in FIG. 1. An administrator edits page 207 containing the “TRAIN SCHEDULE” portlet 211. In prior art there is generally no system support for configuring the content structure.
Although the content structure given in FIG. 2 is kept deliberately simple, a person skilled in the art will appreciate that the task of configuring the Portlets on the Web pages of a Portal is no more trivial, when the number of Portlets and the depth of the tree increases.
A typical larger enterprise's portal, however, contains large numbers, e.g., thousands of pages and portlets. Due to the complexity of an enterprise portal, manual administration is inefficient as it is time-consuming, error-prone and thus expensive. In addition, in a complex portal it is not possible for a human administrator to capture the entire set of functional and semantic relationships between portlets; thus an Administrator will very often not be able to arrange all portlets properly, such that a user visiting the Portal may easily find all those Portlets which are closely related to each other.
An improper arrangement of portlets including complex arrangements of inter-related Portlets when they are for example spread across different pages, results in a complex content structure and in difficult navigation. This may degrade the usability of the Portal and a user's productivity, as the user has to perform too many switches between pages in order to work with two or more functionally-related portlets. Further, a user risks to finish his visit on the portal uncompleted, for example due to the fact that the user is not aware of some relevant Portlet waiting for him to be called two pages higher in the tree.
Thus, it is basically foreseeable that additional helpdesk support and user training is required or at least recommended in such complex navigation structure.